The present invention relates to a method and apparatus for initiating compression of headers of a stream of packets and refreshing a context related to the packets, wherein the context corresponds to the un-compressed form of the headers of the stream of packets.
In packet switched networks, packets are transmitted between nodes connected to the network to effect communication between the nodes. Information in the packets may include messages and commands such as a request for service, connection management controls, or data. Large transmissions are divided into packets instead of being transmitted as one long string.
The Internet is, for example, a packet switched network. Internet Protocol (IP) is an Internetwork protocol that defines how to format various information into packets and transmit those packets using the Internet. IP provides a near universal delivery system that can operate on almost any underlying network.
Currently IP is defined according to IPv4 with the “v4” indicating version 4 of the Internet Protocol. IPv4 serves what could be called the computer market. The focus of IPv4 is to connect computers together to permit communications over various networks where the computers range from Personal Computers (PC's) to Supercomputers. Most of the computers are attached to Local Area Networks (LAN's) and the vast majority are not mobile. The next generation Internet Protocol is referred to as IPv6 where the “v6” indicates version 6 of the Internet Protocol. IPv6 is intended to be compatible with IPv4 while addressing the needs of high performance networks (e.g., ATM) and low bandwidth networks (e.g., wireless). IPv6 also provides a platform for new Internet functionality that may be required in the future (e.g., telephony, television, video on demand, equipment control).
A common characteristic of IPv4 and IPv6 is the use of an IP header of a particular format for each of the packets for identifying the source, destination and other information related to the packet. The routing header identifies one or more intermediate nodes to be “visited” by the packet on the way to the destination. Since the format of IP headers and routing headers for IPv4 and IPv6 are similar, FIG. 1 illustrates the format of an IP header for IPv6 and FIGS. 2 and 3 illustrate the format of routing headers for IPv6.
The IP header 100 illustrated in FIG. 1 includes a Version field 101 which stores information indicating the IP version number to which the packet corresponds, a Traffic Class field 102 which stores information indicating the desired delivery priority of the packet relative to other packets, a Flow Label field 103 which stores information indicating that the packet requires special handling such as a non-default quality of service, a Payload Length field 104 which stores information indicating the length of the rest of the packet following the IP header, a Next Header field 105 which stores information identifying the type of header immediately following the IP header, a Hop Limit field 106 which stores a value indicating the maximum number of hops permitted for the packet, wherein the value is decremented by one by each node that forwards the packet and the packet is discarded if the value is decremented to zero, a Source Address field 107 which stores the address of the initial sender (source apparatus) of the packet, and a Destination Address field 108 which stores the address of the intended recipient (destination apparatus) of the packet.
The routing header 200 illustrated in FIG. 2 includes a Next Header field 201 which stores information identifying the type of header immediately following the Routing header, a Header Extension Length field 202 which stores information indicating the length of the routing header, a Routing Type field 203 which stores information indicating the variant of the routing header, a Segments Left field 204 which stores a value indicating the number of route segments remaining still to be visited by the packet before the destination is reached, and a Type-Specific Data field 205 which stores information including addresses of the nodes to be visited by the packet.
The routing header 300 illustrated in FIG. 3 is a routing header where the Routing Type field 203 has a value of “0”, thereby identifying it as a Type 0 routing header. The Type 0 routing header 300 illustrated in FIG. 3 includes all of the fields shown in the routing header 200 illustrated in FIG. 2 with the exception of a Reserved field 301 which is initialized by the source and can be used in any manner by the intermediate nodes, and Address fields 302-1 to 302-n which include a sequence of addresses of nodes to which the packet is to be routed including the address of the destination. For the type 0 routing header 300, the bits of the Reserved field 301 are all set to “0”. Thus, in order to implement an IP header compression scheme, a routing header of its own is needed.
Much of the header information stays the same over the lifetime of a packet stream. For Non-Transmission Control Protocol (TCP) packet streams, almost all fields of the headers are constant. For TCP packet streams, many fields of the headers are constant and others change with small and predictable values.
To initiate compression of the headers of a packet stream, a packet having a full header (Full Header Packet) carrying Context Identifier (CID) and generation fields are transmitted over the link between first and second nodes as part of the Length fields of the IP header. The compressor (first node) and decompressor (second node) store most fields of this full header as the context which is referred to by the CID. The context includes each of the fields of the header whose values are constant and thus need not be sent over the link at all, or change little between consecutive headers so that it uses fewer bits to send the difference from the previous value compared to sending the absolute value. Thus, after the full header packet is transmitted, subsequent packets are transmitted without headers or with compressed headers having the CID and information of the headers that is unpredictable.
Any change in fields that are expected to be constant in a packet stream will cause the compressor to send a full header packet again to update the context at the decompressor, thereby refreshing the context. As long as the context is the same at the compressor and decompressor, headers can be decompressed to be exactly as they were before compression. However, if a full header packet or compressed header packet is lost during transmission, then the context of the decompressor may become obsolete as it has not been updated properly. Compressed headers will then be decompressed improperly.
Compressing IP headers in the manner described above conserves the bandwidth of slow or medium speed links. The need for compression of IP headers is even greater for IPv6 systems due to the length of the IP headers and the desire to address the needs of high performance systems. The auto-configuration feature of IPv6 makes it attractive for mobile applications. Link speeds in systems implementing mobile applications are often relatively low, however the number of the such systems can be large, thereby making it highly desirable to use header compression.
The above described method of performing IP header compression is disclosed in “IP Header Compression”, by M. Degermark, et al, Internet Draft, Networking Group IETF, February 1999 (Reference 1). The method disclosed in Reference 1 is based on the IPv4 header compression method disclosed in “Compressing TCP/IP Header for Low Speed Serial Length RFC 1144”, Networking Group IETF, February 1990 (Reference 2).
However, the method disclosed by Reference 1, which is based on Reference 2, suffers from various disadvantages. Namely, when initiating IP header compression, the CID and generation which are included in the Length fields of the IP header must be passed to the IP layer by the underlying network layer. The length of the CID and generation fields varies depending on the transported protocol. Thus, the disclosed method requires that a node, such as a router, thoroughly examine and process the nested headers of each and every packet to detect when header compression is to be initiated. Such a procedure requires significant overhead, thereby reducing the efficiency of the network. Further, the disclosed method preempts the use of padding in layer 2 packets.